home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16479 < prev    next >
Encoding:
Text File  |  1996-08-05  |  5.1 KB  |  113 lines
  1. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  2. Path: new-news.sprintlink.net!eskimo!scs
  3. From: scs@eskimo.com (Steve Summit)
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. X-Nntp-Posting-Host: eskimo.com
  6. Message-ID: <DpnxAF.6xq@eskimo.com>
  7. Followup-To: comp.lang.ada,comp.lang.c,comp.lang.c++
  8. Sender: news@eskimo.com (News User Id)
  9. Organization: schmorganization
  10. References: <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk> <dewar.828987544@schonberg> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU>
  11. Date: Wed, 10 Apr 1996 20:08:39 GMT
  12.  
  13. [followups trimmed, and should probably be trimmed further]
  14.  
  15. In article <dewar.828987544@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
  16. > Lots of code is portable and broken, lots of code is (deliberately)
  17. > non-portable and definitely not broken. Lots of code is carefully
  18. > written to be portable, but runs into bugs in supposedly conforming
  19. > implementations. Lots of code uses features that are useful, but for
  20. > which no standard exists, and hence may run into portability problems.
  21.  
  22. All true.
  23.  
  24. > Equating portability with non-brokenness in general is naive. Even in
  25. > an environment with a definite standard, writing portable code requires
  26. > a lot more than just adhering to the letter of the standard!
  27.  
  28. Also true.  There's a lot of naivete in some of the knee-jerk
  29. reactions about portability and conformance which tend to get
  30. made here.  (I'm probably guilty of this myself.)
  31.  
  32. Perhaps the essence of the debate is getting lost in the shouting.
  33. An example was brought up which, I gather, boils down to
  34.  
  35.     char buf[100];
  36.     /* exactly 68 characters are known to be available on fd */
  37.     read(fd, buf, 1000);
  38.  
  39. It wasn't clear whether this was being presented as a real-world
  40. example of a portability problem, or as an example of code that
  41. someone thinks should be written, should be portable in practice,
  42. and should work.  (I sincerely hope it's the former, and Robert
  43. Dewar has assured me that he, for one, is not defending it.)
  44.  
  45. Asserting that non-strictly-conforming programs are not C
  46. programs, or that Good programs are Portable, or that Unix is
  47. standard, is naive.  But deliberately pushing the boundaries of
  48. what is conforming, or even worse, arguing that code which is
  49. obviously dubious but which "obviously has to work" therefore
  50. *must* work, is variously foolish, misguided, culpable, criminal,
  51. and/or suicidal.
  52.  
  53.  
  54. In article <4kbrt5$k3h@mulga.cs.mu.OZ.AU>, fjh@munta.cs.mu.OZ.AU
  55. (Fergus Henderson) writes:
  56. > seebs@solutions.solon.com (Peter Seebach) writes:
  57. >> ... The [undefined] behavior you're used to...
  58. >> is not a portability problem, it's broken code.)
  59. > 
  60. > It's a portability problem AND it's broken code.
  61.  
  62. What Fergus says is also true.  Where the distinction arises is
  63. in one's reaction once the problem is discovered.  Some people
  64. (I'd like to say most people) are aghast when they discover code
  65. as broken as
  66.  
  67.     char buf[100]; read(fd, buf, 1000);
  68.  
  69. and hasten to fix it.  It seems that others, though, engage in
  70. lengthy arguments about what some standard ought to say that the
  71. code in question ought to do, as if the code in question ought to
  72. do anything useful.
  73.  
  74. Let's not lose sight of the end goal here, which is neither to
  75. spend the rest of our days arguing about standards nor fixing
  76. bugs, but rather to write useful programs that work.  Yes, it's
  77. hard to write a correct program.  Yes, it's even harder to write
  78. an airtight standard.  Yes, compromises between the letter of a
  79. standard and the peculiarities of existing practice are often
  80. required when writing compilers.  But chortling with glee as you
  81. discover that you can call read(fd, buf, 1000) even though buf is
  82. only 100 characters long, because you've oh-so-cleverly noticed
  83. and oh-so-carefully proved that fd can contain no more than 68
  84. remaining characters, is not the sort of behavior that's likely
  85. to lead to long-term stability of one's programs or adulation
  86. from one's successors.  Nor, evidently, does coming back with
  87. "But where does which standard say it's illegal?" immediately
  88. endear you to some of your fellow supplicants on this mortal coil
  89. here.
  90.  
  91. (Yes, the 68-character-buffer example is an extreme one, and no
  92. one in this thread has been "chortling with glee."  But it's
  93. reminiscent of the kind of arguments that come up all the time.)
  94.  
  95. The wise thing to do, it seems to me, is to fix the bugs and
  96. overt portability problems, try to figure out better ways of
  97. avoiding them in the future, and move on.  If the documentation
  98. needs to be rewritten to make it clear that the N in "read() may
  99. return -1, with errno set to EFAULT, if buf does not point to at
  100. least N contiguous bytes of writable storage" is the N that is
  101. read's third argument, then so be it.  (If the documentation
  102. doesn't even mention EFAULT or buf's allocation, that may be a
  103. bigger problem.)  Is there really anything else that needs
  104. discussing here?
  105.  
  106. (Actually, of course, none of this needs discussing "here,"
  107. where "here" is the set of newsgroups this thread is currently
  108. crossposted to.  It probably belongs in comp.std.unix, or
  109. comp.programming, or comp.software-eng.)
  110.  
  111.                     Steve Summit
  112.                     scs@eskimo.com
  113.